home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950929-19951130 / 000168_news@columbia.edu_Sat Oct 21 15:20:22 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA05983
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sat, 21 Oct 1995 11:20:30 -0400
  3. Received: by apakabar.cc.columbia.edu id AA25781
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sat, 21 Oct 1995 11:20:28 -0400
  5. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  6. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Problem with remote host command
  9. Date: 21 Oct 1995 15:20:22 GMT
  10. Organization: Columbia University
  11. Lines: 35
  12. Message-Id: <46b33m$p5j@apakabar.cc.columbia.edu>
  13. References: <jaypeeDGsB4x.87y@netcom.com>
  14. Nntp-Posting-Host: watsun.cc.columbia.edu
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <jaypeeDGsB4x.87y@netcom.com>,
  18. John Peterson <jaypee@netcom.com> wrote:
  19. >   I'm trying to issue a "remote host ..." command from a UNIX SVR4 system
  20. >[under release C-Kermit 5A(190)] to an OS/2 system [running C-Kermit 5A(191)
  21. >in server mode]. The remote process on the OS/2 system takes a non-trivial
  22. >period of time to execute. (Specifically a ghostscript process, that takes
  23. >about 4-5 minutes).  The UNIX kermit seems to send NAKs too often, and
  24. >eventually I get the message:
  25. >
  26. >      ?Sent too many NAKs
  27. >
  28. >I was under the impression that issuing a "set server timeout 0" would
  29. >disble the NAKs to the server, but it doesn't seem to help at all. I tried
  30. >huge values like 1000000000 too, and the results are no different. What am
  31. >I missing here?
  32. >
  33. No, it's not SET SERVER TIMEOUT.  That governs the behavior of the server
  34. when it is waiting for a command from the client.
  35.  
  36. In this case, the server *has* received a command from the client and has
  37. started an inferior process, and is blocked waiting for the process to
  38. complete (or to send output, which ghostscript is evidently not doing,
  39. since it is busy painting the OS/2 screen).  Meanwhile, the *client* is
  40. waiting for a reply and none is coming.  Of course the server has no idea
  41. how long the "host" command will take, so it has no way of telling the
  42. client.
  43.  
  44. So in this case you have to adjust the client, using "set send/receive
  45. timeout" and/or "set retry".
  46.  
  47. It would not be unreasonable to expect the server to send some kind of
  48. periodic "hold on, I'm working" type of message to avoid this type of
  49. situation; perhaps this can be added in some future release.
  50.  
  51. - Frank